CECHO-697 [Tempo][SDK] Smart contract call support for Tempo

@claude review this PR.

@copilot Review

@copilot Review

Here's my review of the PR changes:

Summary

The PR adds smart contract call support to sdk-coin-tempo via a new RawContractCall type and addRawCall() builder method. The core approach (separating TIP-20 operations from raw contract calls, preserving calldata through round-trips, and updating verify logic) is sound. Tests are comprehensive. A few issues worth noting:

🔴 Call Order Not Preserved in Mixed Transactions

In buildImplementation, raw calls are always appended after all operations, regardless of insertion order:

const calls = this.operations.map((op) => this.operationToCall(op));
for (const rawCall of this.rawCalls) {
  calls.push({ to: rawCall.to, data: rawCall.data, value: ... });
}

So builder.addRawCall(x).addOperation(y) produces a transaction with [y, x] on-chain — not the user-specified [x, y]. For atomic batch calls where execution order matters (e.g., approve-then-mint), this silently reorders calls. The builder should maintain a single interleaved call list to preserve insertion order.

🟡 Type Safety: (recipient as any).data in verifyTransaction

if ((recipient as any).data) {

Using any bypasses TypeScript's type system and is fragile. Consider defining an extended recipient interface:

interface RawCallRecipient extends TransactionRecipient {
  data?: string;
}

Or use hasOwnProperty/'data' in recipient with a type guard instead of any.

🟡 Missing Validation for RawContractCall.value

addRawCall() validates to and data, but not value. If a caller passes value: "not-a-number", BigInt("not-a-number") will throw an uncaught error at build time. Should validate with something like if (call.value !== undefined && !/^\d+$/.test(call.value)) throw ....

🟡 _inputs Excludes Raw Call Native Value

In Tip20Transaction constructor, _inputs only sums token transfer amounts:

const totalUnits = operations.reduce((sum, op) => sum + amountToTip20Units(op.amount), 0n);

Native ETH value in raw calls (via call.value) is not included in _inputs. This can cause accounting discrepancies when raw calls carry native value.

🟢 value: "0" vs undefined After Deserialization

When a raw call with no value (undefined) goes through a round-trip, it comes back with value: "0" (from call.value.toString() where call.value is 0n). This is harmless functionally but changes the shape of the object. Can be fixed in fromTip20Transaction by conditionally setting value only when non-zero:

value: call.value !== 0n ? call.value.toString() : undefined

✅ What Looks Good

• decodeCallToOperation returning null for non-transferWithMemo calls is the correct fix for the round-trip correctness issue
• isValidHexData utility is clean and well-tested
• The validateTransaction() change allowing raw-call-only transactions is correct
• Test coverage is solid: round-trip (unsigned + signed), mixed batches, verification mismatches

@claude